api: expose root Stats::Scope via Api::Api#6712
api: expose root Stats::Scope via Api::Api#6712mattklein123 merged 17 commits intoenvoyproxy:masterfrom
Conversation
Signed-off-by: Ashley Hedberg <ahedberg@google.com>
Signed-off-by: Ashley Hedberg <ahedberg@google.com>
This reverts commit 2728a65. Signed-off-by: Ashley Hedberg <ahedberg@google.com>
mattklein123
left a comment
There was a problem hiding this comment.
Thanks, LGTM. Is it possible to add a test somewhere that actually uses this in a similar way to what you are going to do in your private filter? We have integration test filters now so it might be easy enough to do there. Thank you!
/wait
Signed-off-by: Ashley Hedberg <ahedberg@google.com>
Signed-off-by: Ashley Hedberg <ahedberg@google.com>
|
Still working on tests, but wanted to throw up the APIs for early feedback. |
Looks great, thank you. /wait |
eds_ready_filter.cc) Signed-off-by: Ashley Hedberg <ahedberg@google.com>
it through the rootScope. Signed-off-by: Ashley Hedberg <ahedberg@google.com>
|
@jmarantz - any idea why the new eds_ready_filter can't find the stat in the root scope? Some very hacky debug logging suggests that the "cluster.cluster_0.membership_healthy" stat is added to scopes whose parent is the root scope, but querying the root scope for that stat returns nothing. |
find* Signed-off-by: Ashley Hedberg <ahedberg@google.com>
Signed-off-by: Ashley Hedberg <ahedberg@google.com>
Signed-off-by: Ashley Hedberg <ahedberg@google.com>
Signed-off-by: Ashley Hedberg <ahedberg@google.com>
Signed-off-by: Ashley Hedberg <ahedberg@google.com>
|
We have an integration test! I think the main outstanding questions here are:
|
jmarantz
left a comment
There was a problem hiding this comment.
This looks basically ready to go; just one simplification comment and a nit or two.
| } | ||
|
|
||
| std::shared_ptr<StatType>* central_ref = &(iter->second); | ||
| if (tls_cache) { |
There was a problem hiding this comment.
I think you indicated 'done' in the comment I made earlier suggesting we not bother with the tls cache, since you are holding a lock anyway. I see you are no longer reading from it, but I'm not sure that usage of the 'find' method is a good signal that we should populate the current thread's cache. In particular -- not really fully understanding the application -- I was wondering if this might tend to be run from the main thread, whose tls cache will (I believe) be consulted approximately never. @mattklein123 & @fredlas for opinions on this.
There was a problem hiding this comment.
Ah, I see--I think I misunderstood a previous conversation that we should populate the tls cache upon reading. I don't feel strongly either way.
We're planning on calling this from a filter, similar to eds_ready_filter.cc, if that changes anyone else's opinions.
Signed-off-by: Ashley Hedberg <ahedberg@google.com>
Signed-off-by: Ashley Hedberg <ahedberg@google.com>
jmarantz
left a comment
There was a problem hiding this comment.
Thanks @ahedberg -- looks great. I am in favor of this simpler approach since you are holding the lock anyway, the tls cache doesn't add value for this flow.
And the confusion you had earlier was my fault -- I had mistakenly suggested you populate the tls cache because I did not realize you had to hold the lock anyway to loop over scopes_.
mattklein123
left a comment
There was a problem hiding this comment.
Thanks looks awesome. 1 question and comment.
/wait
Signed-off-by: Ashley Hedberg <ahedberg@google.com>
|
@ahedberg I'm pretty confused about how the OSX build is failing and not the others, but the failure looks legit. Can you take a look? /wait-any |
Signed-off-by: Ashley Hedberg <ahedberg@google.com>
|
Switched to the version of sendLocalReply accepting response details, both because it's not deprecated and because MacOS doesn't seem to realize the other one exists. ¯_(ツ)_/¯ |
Signed-off-by: Ashley Hedberg <ahedberg@google.com>
mattklein123
left a comment
There was a problem hiding this comment.
I suspect that Azure pipelines is actually merging master before it runs CI which is kind of interesting, and that's why it caught this error. @lizan is that true? Is that expected?
Description: Add
rootScope()to Api::Api so stats can be read by filters, etc. without making an admin request.Risk Level: Low
Testing: bazel test //test/...
Docs Changes: N/A
Release Notes: N/A (but happy to add if warranted)
Fixes #6706